Embedding a watermark in a coded signal

ABSTRACT

Method and arrangement for water(re)marking a compressed video signal by modifying selected DCT coefficients. To avoid that the bitrate is thereby reduced too much, selected variable-length codewords are represented by escape codes. In order to avoid that ESC codes increase the bitrate too much (an ESC code is 7-21 bits longer than the corresponding VLC word), the bitrate is controlled in units of small data chunks. While a VLC is processed, a table is filled with candidate ESC codes. The bitrate controller tries to make the difference between original and processed data chunks zero by re-encoding one VLC into an appropriate ESC code.

This invention relates to watermarking a coded signal, particularly, butnot limited to, a method of watermarking a compressed video signal.

Watermarking of coded signals, particularly compressed coded signals, isachieved with a fixed size of compressed data which forms part of alarger datastream. In order to add a watermark a few code words in thecompressed data are changed. This results in a change of the data size.In order to merge the re-encoded data, which may be said to be in a datachunk, into the original datastream, the data size must be the same asthe original fixed size, in order to prevent problems withsynchronisation and syntax correctness etc.

A known method of embedding a watermark in a compressed media signal isdisclosed in F. Hartung and B. Girod; “Digital watermarking of MPEG2coded video in the bitstream domain”, published in ICASSP, vol 4, 1997pp 2621-2624. In this prior art publication, the media signal is a videosignal, the signal samples of which are discrete cosine transform (DCT)coefficients obtained by subjecting the image pixels to a DCT. Thewatermark is a DCT transformed pseudo-noise sequence. The watermark isembedded by adding the DCT transformed noise sequence to thecorresponding DCT coefficients of the video signals. The coefficientswith a value of zero of the MPEG-coded signal are not affected.

A problem of the prior art watermark embedding scheme is thatmodification of DCT coefficients in an already compressed bitstreamchanges the bit rate, because the DCT coefficients are represented byvariable-length code words. An increased bit rate is usually notacceptable, for the reasons mentioned above. The prior art embeddertherefore checks whether transmission of the watermarked coefficientincreases the bit rate, and transmits the original coefficient in thatcase. But also, reduction of the bit rate is not desired. In MPEGsystems, for example, the change of the bit rate may result in overflowor underflow of buffers in the decoder, and change the position oftiming information in the bitstream.

It may be necessary to increase the size of the data chunks in order toequalise with the original fixed size of the datastream. The only way toget data expansion of this type in small data chunks is re-encodingvariable length codes (VLCs) as Escape codes. The process known as bitstuffing, i.e. adding additional bits to “pack out” the data chunk tothe required size, is not possible, because start codes are not presentin most data chunks. A problem is that the result of Escape coding isnot predictable. For instance, using MPEG re-encoding the smallestDCT-VLC as an Escape code results in a 21-bit increase in the number ofbits. Re-encoding the largest DCT-VLC as an Escape code results in a bitincrease of 7-bits. Re-encoding the other DCT-VLCs as Escape codesgenerates increases between 7 and 21 bits. Consequently, an increase ofbetween 1 and 6 bits is impossible to generate and increases of morethan 21-bits must be generated by re-encoding multiple DCT-VLCs asEscape codes. Furthermore, it is impossible to know in advance whichVLCs are present in the data chunk to re-encode as Escape codes. In theworst case, there is no suitable VLC present. In order to obtain a bitincrease of 300-bits, a combination must be found of a number of VLCswhich coded as Escape codes together exactly generate this amount ofbits. This provides a particularly difficult problem to solve. It cannot be determined in advance how long it will take to find the rightcombination. In order to solve this problem using a search algorithm inreal-time requires a very powerful processor or an enormous amount ofmemory. Both of these possible solutions are unacceptable requirementsin the field of consumer electronics where this problem is encountered,because of costs.

Further background information can be found in the applicant'sunpublished co-pending International Patent Application IB02/02737(Attorney's docket PHNL010493EPP).

Consequently, an alternative solution to the problem of matching datasizes is required.

It is an object of the present invention to address the above mentioneddisadvantages.

According to a first aspect of the present invention, a method ofprocessing a compressed media signal is provided, in which samples ofsaid media signal are represented by variable-length code words (VLCs),the method comprising the steps of:

-   -   decoding the VLCs of a sample;    -   modifying a plurality of said decoded VLCs in accordance with a        given signal processing algorithm;    -   encoding the modified decoded VLCs into modified VLCs by a first        coding method;    -   encoding the modified decoded VLCs into at least one length of        code by a second coding method;    -   for each of the plurality of modified VLCs, selecting the        modified VLC coded by the first or second method that has a        length closest to the length of the corresponding unmodified        VLC, and    -   combining the selected modified VLCs and any unmodified VLCs.

Preferably, the first coding method is a standard VLC coding method.Preferably, the second coding method is an Escape coding method.

The second coding method may be another watermarking algorithm that mayincrease the bit size of a VLC or may be an algorithm that simply addsnoise to VLC coefficients to increase the bit size thereof.

Preferably, the modified encoded VLCs are encoded into a plurality oflengths using the second coding method, preferably the second codingmethod provides codes from 7 to 21 bits longer than the first codingmethod.

The signal processing algorithm is preferably a watermark algorithm.

Preferably, the decoded VLCs are only modified under certain criteria,said criteria affecting the visibility of an applied watermark.

The method may involve inserting bits into the encoded modified VLCs,preferably by bit-stuffing techniques, preferably for the modified VLCscoded by the first coding method.

The method preferably involves the treatment of packets of VLCs,preferably 188 byte packets, individually, without reference to otherpackets.

According to another aspect of the invention a signal processing devicefor a compressed media signal comprises:

-   -   a decoder operable to decode samples of a compressed media        signal represented by variable-length code words (VLCs);    -   means for modifying a plurality of the decoded VLCs in        accordance with a given signal processing algorithm;    -   a first encoder operable to encode the modified decoded VLCs        into modified VLCs by a first coding method;    -   a second encoder operable to encode the modified decoded VLCs        into modified VLCs by a second coding method;    -   memory means operable to buffer the modified decoded VLCs from        the fist and second encoders; and    -   a controller operable to select the modified VLC from either the        first or second encoder closest in length to an unmodified VLC,        for each of the plurality of modified VLCs.

The controller is preferably a bit-rate controller.

The signal processing device is preferably a watermarking device.

For a better understanding of the invention and to show how the same maybe brought into effect, specific embodiments of the present inventionwill now be described, by way of example, with reference to theaccompanying drawings, in which:

FIG. 1 is a schematic diagram showing a scheme for re-marking video datacoded in an MPEG2 transport stream (TS) format;

FIG. 2 is a schematic diagram of the packet remarker shown in FIG. 1;and

FIG. 3 is a schematic diagram of a RAM memory element of the packageremarker shown in FIG. 2.

The following method describes an algorithm for inserting a “no morecopies” watermark in a (possibly already watermarked) video signal inMPEG2 transport stream (TS) or program stream (PS) format. Furtherinformation concerning the MPEG2 video compression standard can be foundat:

[ISO96:1] ISO/IEC 13818:1:1996(E), “Information Technology—GenericCoding of Moving Pictures and Associated Audio Information: Systems”,Video International Standard, 1996, and

[ISO96:2] ISO/IEC 13818:2:1996(E), “Information Technology—GenericCoding of Moving Pictures and Associated Audio Information: Video”,Video International Standard, 1996.

In Applicant's International Patent Application WO-A-02/060182(hereinafter referred to as “VWM specification”), the basic principal of“run-merging” used by the watermark embedding technique is described.

The problem of using the original algorithm on a transport stream isthat it either requires a large amount of memory or the bit-rate controlneeds to be executed on small packets. As this would decrease theeffectiveness of the embedding substantially, the algorithm describedbelow has a far more sophisticated bit-rate control, using 3 tools: therun-merge algorithm (which decreases the amount of bits), the use ofEscape-coding and the addition of stuffing bits (both of which increasethe amount of bits). In this way it is possible to do an effectiveembedding with bit-rate control per packet at an acceptable cost interms of memory and computational complexity. As the packets in atransport stream are smaller than those for a program stream (188 bytesvs. 2 Kilobyte), we focus on a solution for transport streams (TS). ThePS solution is derived from the TS solution by dividing the PS packetsinto sub-packets of 188 bytes and processing the sub-packets in the sameway as the TS-packets.

The TS/PS algorithm described below has the following features:

-   -   it uses the standard run merge technique with adapted bit rate        control;    -   it remarks each 188 byte TS packet individually without        reference to other TS packets to avoid de-multiplexing and        re-multiplexing;    -   it remarks only one video elementary stream (VES) from a range        of video streams in TS, selected by one particular packet        identifier (PID) (extension to parallel remarking is possible).

The main problem in adapting Video Elementary Stream (VES) remarker fromthe VWM Specification referred to above to the case of TS streams isthat either it requires a very large amount of memory, or it requiresbit-rate control (making sure that the remarked stream has the same sizeas the original stream) per TS packet. The former is prohibitive becauseof a large increase of silicon-cost. In the latter case the bit-ratecontrol needs to be much more complicated than in the original VESsolution in order to achieve a sufficient embedding strength. Therun-merge technique underlying the remarker has a strong tendency todecrease the length of the stream. The bit-rate control for the VESremarker uses insertion of stuffing bits to again increase the length ofthe stream to make it the same size as the original stream. Within oneTS packet there is only very limited room for insertion of stuffingbits. This implies that additional tools are needed to increase thelength of the stream. For this, the use of Escape-coding is introduced.This is a versatile tool, as it gives the possibility to replace each ofthe VLCs in the remarked stream by an Escape-code. The difficulty ofthis versatility is that the decision whether a run-level pair isVLC-encoded or Escape-coded creates a very difficult combinatorialproblem. The bit-rate control algorithm described in the next section isa sub-optimal solution with a strongly reduced complexity relative tothe optimal solution.

As depicted in FIG. 1, a remarker 10 consists of three basic blocks: theVES (Video Elementary Stream) extractor 12, the packet remarker 14 andthe TS reconstructor 16.

Operation of the elements is as follows.

The VES extractor 12 splits a TS packet 18 into two smaller chunks, achunk 20 containing the VES-bytes of the video stream corresponding withthe PID that has to be remarked and a chunk 22 with all other data, e.g.TS header, PES header, audio bytes, video bytes of other PIDs, etc.

The packet remarker 14 adds the remark to the chunk 20 with VES bytes insuch a way that a watermarked output chunk 20 a has exactly the samenumber of bits as the original input chunk 20. A detailed explanation ofthe workings of the packet remarker 14 is given below.

The TS reconstructor 16 recombines the two chunks 20 a and 22 to build avalid remarked TS stream.

The packet remarker 14 will now be described in more detail.

As explained in the previous section, the main difference compared to aVES remarker is the more complicated bit-rate control. Therefore, inthis section, we explain the workings of the packet remarker 14, with anemphasis on a bit-rate controller element 26. After that we explain infull detail the workings of all components of the packet remarker.

FIG. 2 presents the basic blocks of the packet remarker 14. To realisethe adapted bit-rate control, the remarker 14 has been designed around acentral piece of RAM memory 28. All operations are carried out oninformation stored in this memory 28. The most complex aspect of theembedding is the bit-rate control. This induces a strong interactionbetween the bit-rate controller 26 and the memory 28, but also an MPEGparser 30 and a finaliser 32 operate upon the memory.

Upon reception of an incoming chunk 20, the MPEG parser 30 extracts allAC-VLCs. These are sent to a VLC processor 34 together with associatedinformation, like MPEG encoding parameters and the spatial position inthe frame of the corresponding macro-block. The VLC processor 34contains the core run-merge technique, as described in the VWMspecification above. It decodes the incoming luminance AC-VLCs torun-level pairs and subsequently this stream of run-level pairs ischanged, based on the information in a WM DCT buffer 36 (containing thechange direction for the AC-VLCs, as derived from the spatial watermarkpattern). The resulting run-level pairs are then sent to the bit-ratecontroller 26. Note that, due to the application of the run-mergetechnique, there will be a smaller number of run-level pairs coming outof the VLC processor 34 than came into it. The bit-rate controller 26encodes the watermarked run-level pairs and sends them to the memory 28.This is done in a way (as explained in the paragraph below) so as tomaximise the part of the remarked chunk 20 a that is as big as thecorresponding part of the original stream 20. The finaliser 32 thencreates a remarked chunk 20 a of the same size as the original byreplacing this corresponding part in the original 20 stream by itsremarked counterpart. The resulting chunk 20 is then sent to the TSreconstructor 16 (see FIG. 1).

Let us explain the approach taken by the bit-rate controller 26. Theoverall bit-rate control strategy is based on keeping the size of theremarked version 20 a as close as possible to the original one 20. Oneof the ways to achieve this is to add stuffing bits before a start-code,in the same way as for the VES remarker described in the VWMSpecification. However, the main way is by use of Escape-coding. A copyof the original chunk 20 is stored in the memory 28 (in a so-called“backup buffer” 40, see FIG. 3). The remarked version of the chunk isstored in a so-called “write buffer” 42 in FIG. 3. In the write buffer42 we place two pointers, indicating the start and the end of a piece ofthe watermarked chunk 20 a which has exactly the same size as thecorresponding part of the unwatermarked chunk 20. Upon reception of arun-level pair, the VLC of the run-level pair is computed. It is addedto the write buffer 42 in memory 28. Moreover, in an “Escape-table” 44in memory 28 an entry is created, indexed by the difference in lengthbetween the VLC (size between 3 and 17 bits) and the correspondingEscape-code (fixed size of 24 bits). Now, the difference in lengthbetween the write buffer 42 and the backup buffer 40 is computed.

If the Escape-table 44 contains an entry for which the difference insize between the VLC and the Escape-code is equal to the difference inbuffer lengths, then the corresponding VLC is replaced by theEscape-code. Note that now the buffers 40, 42 contain two correspondingparts of exactly the same size. Hence, the two pointers in the writebuffer 42 need to be updated.

If the difference in length between the two buffers 40, 42 is too largeto be completely removed, in the way as described above, the bit-ratecontroller 26 will try to reduce the difference in length, also byreplacing VLCs by Escape-codes. To reduce the number of changes, thereplacement with the largest increase in code-size is used.

Next we explain all components in full detail.

MPEG Parser

The MPEG parser 30 has two tasks. Its first task is to partiallyinterpret the MPEG stream to gather information about the luminance VLCs(I, P and B frames). It collects the following information:

-   top (x, y )-co-ordinates of source macro-block-   position of source 8×8 block in corresponding macro-block-   scan position VLC in the 8×8 block-   scan type (zigzag, alternating)-   VLC code type (field, frame)-   Quantization step size-   VLC size-   Current Picture type-   Current macro-block type

Furthermore it searches for bit-stuffing locations. These are thelocations before the start codes (indicated by the variable “start-codestart” and communicated by the parser 30 to the bit-rate controller 26).The parser 30 also indicates when a chunk starts or ends.

Its second task is to extract AC-VLCs representing luminance andchrominance AC-DCTs from the MPEG stream. The AC-VLCs are passed on tothe VLC processor 34 together with the information about the VLCs. Alloriginal MPEG code-words are also passed on to the memory (RAM) block28. Each code-word is stored in the memory 28 together with a flagindicating whether the code-word is a full AC-VLC or not. Only completeVLCs are passed on to the VLC-processor 34; VLCs crossing the boundaryof a chunk are not taken into account by the VLC processor 34.

VLC Processor

In the VLC-Processor 34 the actual embedding takes place. It receivesthe AC-VLCs, both from the luminance and the chrominance components. Thechrominance AC-VLCs are just decoded and the resulting run-level pairsare passed on to the bit-rate controller 26. The luminance AC-VLCs areprocessed to embed the watermark. This is done in the same way as in theVES remarker described in the VWM Specification above. A briefdescription is given below and the interested reader is referred to theVWM Specification document for more detailed information and figures.Starting with VLCs representing run-level pairs of luminance AC-DCTcoefficients, the following tasks are performed:

1. Decode VLCs to run-level pairs;

2. Select candidate run-level pairs from the luminance DCT coefficients.A candidate run-level pair is a run-level pair with a level equal to −1or 1;

3. Calculate WM buffer address of the DCT change direction thatcorresponds with the VLC. Fetch the change direction from the WM-DCTbuffer 36;

4. Selectively merge candidate (run, level) pairs if the following 4conditions are satisfied:

4.a The level plus the corresponding change direction in the WM DCTbuffer 36 equals 0, i.e.:

((level=−1) && (WM buffer=+1)) OR ((level=+1) && (WM buffer=−1))

4b. The merge will not affect the visual quality severely according to asimple human visual model.

5. Pass on all processed run-level pairs (for Y, U and V) to thebit-rate controller 26.

The conditions 4.b, 4.c and 4.d control the visibility of the watermark.There are 3 DCT energy thresholds for I,P and B pictures: E_(I), E_(P)and E_(B). These thresholds can limit the number of changes further to0, 1 and 2 as a function of the quantization step. Upon End_of_Block orEnd_of_Chunk, the VLC processor 34 is reset.

WM-DCT Buffer (ROM)

The WM-DCT buffer 36 is described in full detail in the VWMspecification.

Memory (RAM)

The RAM memory 28 is depicted in FIG. 3. It consists of the BackupBuffer 40 and the Write Buffer 42 (both of size 184 bytes) and anEscape-table 44. The MPEG parser 30 stores the original VES data of anincoming chunk 20 in the Backup Buffer (BB) 40. A watermarked version isgenerated in the second buffer, the Write Buffer 42 (WB). The buffers40, 42 are filled from the left to the right. Both buffers have apointer at the first position after the last written bit, named a ReadPointer 46 (RP, for the Backup Buffer 40) and a Write Pointer 48 (WP, inthe Write Buffer 42). The MPEG parser 30 sends all data to the BackupBuffer 40. It also sends all data except the full AC-VLCs to the WriteBuffer 42. The full AC-VLCs for the Write Buffer 42 are generated by thebit-rate controller 26. The memory contains two pointers, named BackupPointer (BP) 50 and Extra Backup Pointer 52 (EBP). In the Write Buffer42, these pointers indicate the end and the start, respectively, of thewatermarked chunk that has exactly the same size as its unwatermarkedcounterpart. These pointers are set by the bit-rate controller. The partin the Write Buffer 42 between the Backup Pointer 50 and the WritePointer 48 indicates the part which has been watermarked, but which doesnot yet have the same size as the corresponding part in the BackupBuffer 40. Usually, the Extra Backup Pointer 52 points to the start ofthe Write Buffer 42. It shifts to the right if the size of the initialpart (between the start of the buffer and a start-code in the buffer) ofthe chunk increases by the run-merge technique (see the section headedStart Code Start, sub-section 1 b below).

The Escape-Table 44 contains 15 rows ranging from 7 to 21. Each row isempty or it describes a certain VLC from the Write Buffer 42. If row i(i ranging from 7 to 21) is not empty, a VLC exists that will increasethe write buffer 42 with i bits when this VLC is replaced by anEscape-code. The Escape-table 44 is administered by the bit-ratecontroller 26. The bit-rate controller 26 will occasionally replace aVLC from this table by an Escape-code to control the bit-rate.

Bit-rate Controller

In this section we will explain the operation of the bit-rate controller26 in full detail. Between the explanation of the actions of thebit-rate controller 26, we have placed “timing notes”, listing the orderin which actions of different modules need to be executed.

There are four different commands coming from different modules, basedon which the bit-rate controller chooses its next action:

-   Chunk Start from the MPEG parser 30;-   New run-level pair from the VLC processor 34;-   Start-code start from the MPEG parser 30;-   End of Chunk from the MPEG parser 30;

The actions taken by the bit-rate controller 26 on these commands aredetailed in the sections below.

Chunk Start

In response to the “Chunk Start” command, the bit-rate controller 26 isreset to its initial position. This encompasses:

1. Labelling all entries of the Escape-table 44 “empty”.

2. Setting the 4 pointers RP 46, WP 48, BP 50 and EBP 52 to 0.

New run-level pair

The bit-rate controller 26 receives the run-level pairs from all(chrominance and luminance) AC-VLCs. For each of these run-level pairs(r,l), it performs the following 6 steps:

1. Request from a VLC generator the VLC v of run-level pair (r,l).

2. Update the Escape-table 44 as follows. Compute the difference Δ_(C)in size between the Escape-code (which is always 24 bits) and the VLC:Δ_(C)=size( Escape-code)—size(v).

Next, row Δ_(C) of the Escape-table 44 is filled:

bit-position=WP 48;

VLC-size=size(v);

run-level=(r,l).

3. Write VLC v into the Write Buffer 42. Update the write pointer 48accordingly.

Timing Note:

I. The MPEG parser 30 sends the original VLC to the memory 28, where itis written in the Backup Buffer 40 (RP 46 is updated).

II. Next the VLC is decoded by the VLC processor and the—possiblymerged—run-level pair is sent to bit-rate controller 26.

III. The bit-rate controller 26 sends the remarked VLC to the memory 28,where it is written in the Write Buffer 42 (WP 48 is updated).

4. Try to make the length of the Write Buffer 42 and the Backup Buffer40 exactly equal. This can be done if:

-   The number of VLCs that has been Escape-coded so far in this chunk    is smaller that the maximum allowed (EM)-   The difference in length Δ_(B) between the Write Buffer 42 and the    Backup Buffer 40 is between 7 and 21: 7≦Δ_(B)≦21-   Row Δ_(B) of the escape table 44 is not empty-   If these conditions are satisfied, then take the following actions:-   Replace the VLC in the Write Buffer 42, as indicated in row Δ_(B) of    the Escape-table 44, by its Escape-coded version (which the bit-rate    controller 26 requests from the VLC generator 56), and shift all    entries following that VLC in the Write Buffer 42 Δ_(B) positions to    the right.-   Update the Escape-table 44:-   All bit positions in the Escape table 44 larger than the one of the    VLC just replaced are increased by Δ_(B)-   Clear row Δ_(B) and label it “empty”-   Update the Write Pointer 48 (now, WP=RP 46)

5. Try to make the length of the Write Buffer 42 and the Backup Buffer40 as small as possible. This is done if:

-   The number of VLCs that has been Escape-coded so far in this chunk    is smaller that the maximum allowed (EM)-   The difference in length between the Write Buffer 42 and the Backup    Buffer 40 (Δ_(B)) is greater than 21: Δ_(B)>21

If these conditions are satisfied, then search in the Escape-table 44from row 21 down to row 7 for the first non-empty row that has a bitposition greater than or equal to the backup pointer BP 50 (this lastcondition is necessary to avoid illegal MPEG syntax with nonbyte-aligned start-codes). If such a row exists, it is defined as row i,and the following actions are executed

-   Replace the VLC described on row i of the Escape-table 44 in the    write buffer 42 by its escape-coded version, which the bit-rate    controller 26 requests from the VLC generator 56, and shift all    entries in the write-buffer 42 following that VLC over i positions    to the right.-   Update the Escape-table 44 as follows:-   All bit positions in the Escape table 44 larger than the one of the    VLC just replaced are increased by i-   Clear row i and label it “empty”

6. Update the Write Pointer 48 (WP=WP+i)

Update the backup pointer 50. If the Write Buffer 42 and the BackupBuffer 40 have the same length (i.e., if WP 48=RP 46), then the backuppointer is shifted: BP 50=WP 48.

Start-code start

Before a start-code, the bit-rate controller 26 has the possibility tomake the size of the Write Buffer 42 and the Backup Buffer 40 equal byadding stuffing bits. Of course, this is only possible if the WriteBuffer 42 is shorter than the Backup Buffer 40. If it is larger than thebackup buffer 40, then the Extra Backup Pointer 52 is shifted to theposition of the Read Pointer 46 (recall that the finaliser 32 uses thepart of the chunk between bit position 0 and EBP 52 from the BackupBuffer 42). Summarising, the following steps are carried out:

1a. If the Write Buffer 42 is smaller than the Backup Buffer 40 (i.e.,WP48 ≦RP42) Write stuffing bits (value=“0”) into the Write Buffer 42 WBuntil the write pointer WP 48 equals read pointer RP 46.

1b. If The Write Buffer 42 is larger than the Backup Buffer 40 (i.e.,WP>RP), reject remarking of the part of the chunk received so far. Thatis, update EBP 52 and WP 48:

-   EBP=RP,-   WP=RP.

2. Write the start-code received from the MPEG parser in the WriteBuffer 42 and the Backup Buffer 40 and update the pointers WP 48 and RP46.

3. Update the Backup Pointer: BP 50=RP 46

4. Clear the Escape-table 44 and label all entries “empty”.

Timing Note:

I. The MPEG parser 30 sends the start-code start signal to the bit-ratecontroller 26.

IIa. EITHER the bit-rate controller 26 writes the appropriate number ofstuffing into the Write Buffer 42 and updates the write pointer 48

Ilb. OR The bit-rate controller 26 rejects remarking of the first partof the chunk and updates EBP 52 and WP 48

III. The MPEG parser 30 writes the start-code both in the Backup Buffer40 and in the Write Buffer 42 and updates the Read Pointer 46 and theWrite Pointer 48.

IV. The Bit-rate controller 26 updates the Backup pointer 50 and clearsthe Escape-table 44.

End of Chunk

Upon receiving the End of Chunk command, the bit-rate controller 26passes it on to the finaliser 32.

Timing Note:

I. The MPEG parser 26 writes the last complete or incomplete VLC in theBackup Buffer 40 and the Write Buffer 42 and updates the pointers RP 46and WP 48.

II. End of Chunk command is passed on to Finaliser 32.

VLC Generator

The VLC generator 56 generates VLC codes for run-level pairs (Table B14and B15 from [ISO96:2] referred to above upon request of the bit-ratecontroller 26. The bit-rate controller 26 also provides a flag if anormal VLC or an Escape-code is requested.

Finaliser

The Finaliser 32 creates a valid output chunk by combining the BackupBuffer 40 and the Write Buffer 42 in the following way:

-   bits 0..EBP-1 from the Backup Buffer 40 are copied to the output    chunk 20 a-   bits EBP..BP-1 from the Write Buffer 42 are copied to the output    chunk 20 a-   bits BP..RP-1 from the Backup Buffer 40 are copied to the output    chunk 20 a

The algorithm described above can easily be extended to deal withprogram streams (PS) as described in [ISO96:1] referred to above. Onlythe VES extractor 12 and the TS reconstructor 16 need to be changed(FIG. 2). The packet remarker 14 remains the same.

The VES extractor 12 reads a PS packet and splits it into two smallerchunks, a chunk containing the VES bytes of the video stream and a chunkwith all other data, e.g. PS header, Packetised Elementary Stream (PES)header, audio bytes, video bytes of other PIDs etc. The chunk 20containing the VES bytes is split in sub-chunks of at most 184 bytes. Asub-chunk will never cross a PES or pack boundary. These sub-chunks areoffered to the unaltered packet remarker 14.

The TS reconstructor 16 needs to be replaced by a PS reconstructor,which recombines the sub-chunks to build a valid PS stream.

The method of watermarking compressed data streams advantageouslyprovides a solution to avoid the high cost of a large memory orcomputational cost that would otherwise result.

The reader's attention is directed to all papers and documents which arefiled concurrently with or previous to this specification in connectionwith this application and which are open to public inspection with thisspecification, and the contents of all such papers and documents areincorporated herein by reference.

All of the features disclosed in this specification (including anyaccompanying claims, abstract and drawings), and/or all of the steps ofany method or process so disclosed, may be combined in any combination,except combinations where at least some of such features and/or stepsare mutually exclusive.

Each feature disclosed in this specification (including any accompanyingclaims, abstract and drawings), may be replaced by alternative featuresserving the same, equivalent or similar purpose, unless expressly statedotherwise. Thus, unless expressly stated otherwise, each featuredisclosed is one example only of a generic series of equivalent orsimilar features.

The invention is not restricted to the details of the foregoingembodiment(s). The invention extends to any novel one, or any novelcombination, of the features disclosed in this specification (includingany accompanying claims, abstract and drawings), or to any novel one, orany novel combination, of the steps of any method or process sodisclosed.

The invention can be summarized as follows. Method and arrangement forwater(re)marking a compressed video signal by modifying selected DCTcoefficients. To avoid that the bitrate is thereby reduced too much,selected variable-length codewords are represented by escape codes. Inorder to avoid that ESC codes increase the bitrate too much (an ESC codeis 7-21 bits longer than the corresponding VLC word), the bitrate iscontrolled in units of small data chunks. While a VLC is processed, atable is filled with candidate ESC codes. The bitrate controller triesto make the difference between original and processed data chunks zeroby re-encoding one VLC into an appropriate ESC code.

1. A method of processing a compressed media signal, in which samples ofsaid media signal are represented by variable-length code words (VLCs),the method comprising the steps of: decoding the VLCs of a sample;modifying a plurality of said decoded VLCs in accordance with a givensignal processing algorithm; encoding the modified decoded VLCs intomodified VLCs by a first coding method; encoding the modified decodedVLCs into at least one length of code by a second coding method; foreach of the plurality of modified VLCS, selecting the modified VLC codedby the first or second method that has a length closest to the length ofthe corresponding unmodified VLC; and combining the selected modifiedVLCs and any unmodified VLCs.
 2. A method as claimed in claim 1, inwhich the first coding method is a standard VLC coding method.
 3. Amethod as claimed in either claim 1, in which the second coding methodis an Escape-coding method.
 4. A method as claimed in claim 1, in whichthe modified encoded VLCs are encoded into a plurality of lengths usingthe second coding method.
 5. A method as claimed in claim 4, in whichthe second coding method provides codes of between approximately 7 to 21bits longer than the first coding method.
 6. A method as claimed inclaim 1, in which the signal processing algorithm is a watermarkalgorithm.
 7. A method as claimed in claim 6, in which the decoded VLCsare only modified under certain criteria, said criteria concerning thevisibility of an applied watermark.
 8. The method as claimed in claim 1,which involves inserting bits into the encoded modified VLCs.
 9. Themethod as claimed in claim 1, which involves the treatment of packets ofVLCs individually, without reference to other packets.
 10. A signalprocessing device for a compressed media signal comprises: a decoderoperable to decode samples of a compressed media signal represented byvariable-length code words (VLCs); means for modifying a plurality ofthe decoded VLCs in accordance with a given signal processing algorithm;a first encoder operable to encode the modified decoded VLCs intomodified VLCs by a first coding method; a second encoder operable toencode the modified decoded VLCs into modified VLCs by a second codingmethod; memory means operable to buffer the modified decoded VLCs fromthe fist and second encoders; and a controller operable to select themodified VLC from either the first or second encoder closest in lengthto an unmodified VLC, for each of the plurality of modified VLCs.